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Abstract 


Whenever the IETF decides to enter into a liaison relationship with 
another organization, such as a Standards Development Organization 
(SDO), a consortium, or an industrial forum, a liaison manager is 
appointed. The procedures used by the IAB to establish and maintain 
liaison relationships between the IETF and other organizations are 
described in RFC 4052. This document expands on the role of liaison 
managers and liaison representatives, giving guidelines on their 
mandate and the expectations, tasks, and responsibilities placed on 
them. 
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1. Introduction 


In the course of developing Internet standards, the IETF needs to 
communicate extensively with various other peer organizations, 
including the following: 


o Standards Development Organizations (SDOs) such as the 
Telecommunication Standardization Sector of the International 
Telecommunication Union (ITU-T) or standardization working groups 
of the Institute of Electrical and Electronics Engineers (e.g., 
TEEE 802) 


o Consortia such as the World Wide Web Consortium (W3C) 
o Industrial forums such as the Global Grid Forum (GGF) 


These organizations are usually concerned with developing related 
standards and technical specifications, so that from time to time 
issues of coordination and mutual interest may arise. To facilitate 
communications, the IETF, through the Internet Architecture Board 
(IAB), establishes permanent liaison relationships with appropriate 
parts of these organizations according to the processes described in 
RFC 4052 [RFC4052]. 


Whenever the IETF decides to enter into a liaison relationship, a 
liaison manager and possibly some liaison representatives are 
appointed by the IAB to act as a channel between the IETF and the 
peer organization, typically in tandem with counterparts appointed by 
the peer organization. 


Sections 2.2, 2.3, and 3 of RFC 4052 briefly set out the basic 
functions of the tasks of liaison managers and representatives. Over 
time, the number and importance of liaisons have grown, and the 
importance of the personal role of IETF liaison managers and 
representatives in maintaining effective relationships with peer 
organizations has grown concomitantly. This document supplements 
[RFC4052] by providing guidelines for liaison managers and liaison 
representatives in maintaining communications to peer organizations. 
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2. IETF Liaison Relationships 


A major goal of the IETF is to develop standards for the Internet, 
enabling the development of interoperable implementations. In order 
to develop Internet standards, it is frequently necessary for the 
IETF to communicate with other organizations that develop standards 
for other types of networks, for Internet applications, or for 
technologies that the Internet uses. 


In some cases, the IETF and peer organizations consider it mutually 
beneficial to have a permanent formal relationship with certain rules 
governing the relationship. The organizations then enter into a 
"liaison relationship". At a high level, both sides agree to 
undertake certain responsibilities with respect to each other. The 
most basic liaison responsibility is to communicate information as 
necessary, and to respond to requests from peer organizations to 
which liaisons are maintained. 


Decisions on IETF liaison relationships are the responsibility of the 
TAB. This includes whether or not the IETF should have a liaison 
relationship with a particular organization. 


2.1. Related Documents 


The IETF liaison process is specified in several documents. RFC 4052 
[RFC4052] specifies how the IAB manages the IETF liaison 
relationship; RFC 4053 [RFC4053] specifies how liaison statements 
should be treated. Organization-specific agreements and documents 
may also be generated in some cases, e.g., RFC 3356 [RFC3356] 
describes the collaboration between the IETF and ITU-T, RFC 3113 
[RFC3113] describes the relationship with the 3rd Generation 
Partnership Project (3GPP), and RFC 3131 [RFC3131] describes the one 
with the Third Generation Partnership Project 2 (3GPP2). 


2.2. Liaison Managers and Liaison Representatives 


Whenever the IETF enters into a liaison relationship with another 
organization, a liaison manager (often referred to as "the IETF 
liaison") is appointed by the IAB. This document expands on the 
mandate of and the expectations, tasks, and responsibilities placed 
on the liaison manager by Section 2.2 of RFC 4052. 


In some cases, it may be necessary to have more than one person 
handling the liaison relationship with a given organization. For 
example, the time commitment required may be too substantial, or the 
technical scope of the liaison relationship may be too broad to be 
handled by a single individual. 
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In such cases, the IAB may appoint one or more liaison 
representatives to supplement the work of the liaison manager by 
managing different aspects of the liaison relationship between the 
IETF and the other organization. 


The value of personal relationships between the IETF liaison manager 
and representatives and members of the peer organization is central 
to the roles. The IAB will be looking for people who have both a 
good technical understanding of the work being carried out and 
effective personal relationships within the peer organization. 
Ongoing face-to-face interactions between the IETF liaisons and 
members of the peer organization are seen as critical to the 
effective functioning of the role. These interactions should allow 
the liaisons to keep the IETF abreast, and preferably ahead, of 
matters of mutual interest or potential conflict. When the liaison 
is working effectively, it should facilitate the IETF and the peer 
organization working synergistically and reduce the chance of 
overlapping or conflicting standards being created. 


2.3. Written Communications 


Aside from the personal contacts between liaisons and the peer 
organization, extensive communication may occur between the IETF and 
the peer organizations through written materials. Much of this 
communication is through liaison statements that typically contain 
plans, new developments, and time schedules of which one party 
believes that the other party should be aware. 


The liaison manager should be aware of these written communications 
and assist both parties to see that appropriate action is taken in 
relation to liaison statements passing in both directions. 


For example, when a liaison organization, such as ITU-T, needs to 
reference material that is under development in the IETF: the final 
reference in the peer organization’s document needs the permanent 
identifier (RFC number) that will be assigned to the Internet Draft 
when it is approved and published. To meet the publication schedule 
of the peer organization, a liaison statement is often sent to the 
IETF requesting that an RFC number be assigned within the required 


timeframe. In response, the IETF can provide the RFC number or 
explain why it is not possible to provide this within the timeframe 
requested. 


An alternative situation that involves more specific action by the 
liaison manager also involves requests for this kind of expedited 
action on RFCs. For example, 3GPP/3GPP2 and the Open Mobile Alliance 
(OMA) provide the IETF with an updated list of dependencies between 
their documents and IETF documents on a monthly basis, indicating 
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what documents are needed and the required timeframe. In this case, 
the liaison manager tracks the dependency list and, when necessary, 
conveys the request for expedited assignment to the appropriate IETF 
Area Director (AD). 


2.4. Terminology and Conventions 


Terminology relating to IETF liaison procedures is found in 
[RFC4052]. Terms defined below are valid for this document only. 


Liaison manager 


A person appointed to manage an IETF liaison relationship with 
another organization. 


Liaison representative 


A person appointed to manage a certain (sub-)aspect of an IETF 
liaison relationship with another organization. Since it is only the 
scale of the responsibilities, mandate, and tasks that is different, 
the rest of this document only explicitly mentions liaison managers. 


IETF consensus 


RFC 2026 [RFC2026] and RFC 2418 [RFC2418] discuss the IETF consensus 
process. In this document, the term "IETF consensus" is used to 
indicate either consensus of the IETF as an organization, an area 
within IETF, or a working group. There the term "IETF consensus" 
needs to be interpreted in the context in which it is used. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. Guidelines for Liaison Managers and Representatives 


Since liaison relationships are intended to be mutually beneficial, 
the IETF liaison to another organization must act as a bi-directional 
communication link between the IETF and the other organization. 

Since the liaison manager has been appointed by the IETF, the liaison 
manager needs to be responsive to the needs and aims of the IETF. 


RFC 4052 lists some of the tasks and expectations relating to liaison 
managers and liaison representatives. This document expands on their 
mandate, provides more detailed discussion, and describes how the 
role is executed. 
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3.1. Mandate 


The mandate for IETF liaison managers is strictly limited to 
conveying IETF consensus to the liaised organization. The liaison 
manager MUST NOT on their own initiative send liaison statements to a 
liaised organization on behalf of IETF, or any of its areas and 
working groups. Liaison statements are only sent following the 
process specified in [RFC4052]. Liaison statements are only sent on 
the initiative of the IETF chair, the IAB chair, IETF Area Directors, 
or IETF working group chairs. 


In Section 3.3 and Section 3.4, responsibilities and tasks are listed 
that enable the IETF to obtain the information to correctly interact 
with the liaised organizations and to develop and clearly communicate 
IETF consensus. 


3.1.1. Speaking for the IETF 


The IETF functions based on rough consensus, which means that the 
right to speak for the IETF cannot be delegated. The liaison manager 
speaks on behalf of the IETF on the subject matter of the liaison, 
but only after making sure that the IETF consensus is understood. 
Some guidelines for understanding IETF consensus are provided above; 
however, the most important requirement is close and detailed 
coordination/consultation with the IETF community. 


3.2. Expectations 


There are certain expectations placed on liaison managers appointed 
by the IETF. Examples of these expectations are listed below. 


Competences required 


The key competence needed in the liaison manager or representative 
role is effective management of the liaison process according to 
the rules that have been agreed upon. The liaison acts as a 
representative of the IETF and not an independent voice with 
respect to topics of discussion in the liaison relationship. The 
liaison must therefore be careful to distinguish his or her own 
views from documented IETF consensus in dealings with the peer 
organization. 


To this end, the liaison manager or representative must be able to 
communicate effectively with members of the peer organization, 
especially in face-to-face situations. This is important both to 
communicate the IETF’s viewpoint and to gather information about 
the issues in the peer organization that the IETF needs to 
understand. 
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In support of the liaison process, a person appointed to act as a 
liaison manager or representative on behalf of the IETF is 
expected to have a good technical understanding of the key issues 
in the subject area, as well as an understanding of the concerns 
important to stakeholders in both organizations. 


An IETF liaison needs to have knowledge of the IETF’s consensus 
process in general, as well as the consensus process(es) applying 
to the key issues within the liaison relationship. 


The liaison must also have a good understanding of the processes 
used by the peer organization involved. 


Perspective 


Liaison relationships are designed for the mutual benefit of the 
organizations participating in the liaison. As such, swift 
information flow in both directions is a firm requirement. The 
role of an IETF liaison manager is to promote the interests of the 
IETF with respect to all topics within the scope of the liaison 
relationship. Since the liaison manager "wears an IETF hat", it 
is NOT the task of a liaison manager to promote the interests of 
the liaised organization within the IETF. 


Distance 


A liaison may not be able to maintain the required perspective if 
he or she is closely involved in the outcome of the work in the 
peer organization. A conflict of interest might arise if the 
liaison is involved in the management of the relevant part of the 
peer organization, has a close technical involvement in the work 
that is the subject of the liaison, or has a close interest in the 
outcome of the work in the peer organization through his or her 
employment. When appointing an appropriate person to manage a 
liaison relationship, the IAB needs to take into account any 
conflicts of interest that the individual being considered might 
have. Before a person is appointed to manage a liaison 
relationship, he or she will be asked to explicitly state any 
conflicts of interest. The IAB will not appoint a person to a 
liaison manager position if there is a strong conflict of 
interest. For example, an individual with an industry or 
organizational leadership position in an organization would 
typically not be suitable for appointment as an IETF liaison to 
that organization. 
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Commitment and opportunity 


A liaison manager needs to be committed to addressing the issues 
relevant to the liaison relationship. To handle the job properly, 
it is necessary that the liaison be able to allocate sufficient 
time to the task. 


Timeliness 


It is expected that a liaison manger will make the IETF aware of 
new developments in the subject area in a timely fashion. 


3.3. Responsibilities 


The liaison manager and representatives provide information to the 
IETF community in order to enable the IETF to make decisions based on 
the best possible information regarding the work in the peer 
organization. In turn, information communicated by the IETF liaison 
to the liaised organization MUST be based on the relevant IETF 
consensus. The liaison manager works with the liaised organization 
to ensure that communication is clear. As part of this, the liaison 
must clearly differentiate his or her own independent positions from 
those that represent IETF consensus. 


It is the responsibility of the liaison manager to ensure that the 
liaised organization communicates its requirements to the IETF ina 
timely fashion and that the IETF consensus is clearly understood. 
This is particularly important in situations where the IETF and the 
liaised organization differ substantially in their positions. In 
this situation, the liaison manager needs to facilitate prompt 
communication so that the IETF and the liaised organization can stay 
in close communication and avoid misunderstandings. 


The liaison manager and representatives are responsible for clearly 
and correctly communicating the IETF consensus position to the 
liaised organization. This includes, when specifically instructed, 
carrying any messages from the IETF to the peer organization. 
Generally, these communications "represent the IETF", and therefore 
due care and consensus must be applied in their construction. 


The liaison manager and representatives are responsible for ensuring 
that relevant information originating from the liaised organization, 
or other information coming to the attention of the liaison, reaches 
the correct destination within the IETF, in a timely and effective 
way. 
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3A: 


Tasks 


Examples of tasks performed by the liaison manager are provided 
below. Depending on the nature of the liaised organization, the task 
may vary in frequency and relative importance. 


1. 


Attend relevant meetings and participate in conference calls and 
mailing lists within the liaised organization to gather 
information relevant to the liaison relationship. Note 
developments of interest for onward communication to the IETF. 
Communicate the point of view of the IETF consensus to the peer 
organization. 


Communicate information relevant to the liaison relationship to 
the relevant part of the IETF either by written reports or 
verbally; this may involve briefings with a team of IETFers 
involved in the liaised organization and other interested parties 
within the IETF, e.g., working group chairs and ADs. 


Understand the concerns of both the IETF and the peer 
organization, while ensuring that interests of the IETF are 
maintained; where there appear to be problems to solve or 
conflicts between approaches, work with both parties to encourage 
engineers from both organizations to collaborate on solving the 
problem and facilitate the development of engineering solutions 
in the appropriate organization. 


Prepare reports giving updates on developments in the peer 
organization as requested by the IAB or other interested parties 
in the IETF. The target for these updates (e.g., the IAB, an AD, 
a WG) will typically be identified upon establishment of the 
liaison relationship and/or the appointment of the liaison 
manager. 


Oversee delivery of liaison statements addressed to the IETF. 
This includes ensuring that liaison statements are delivered to 
the appropriate destination within the IETF, as well as 
shepherding the timely creation of responses by the IETF. 


Work with the liaised organization to ensure that the IETF’s 
liaison statements are appropriately directed and responded to in 
a timely fashion. To accomplish this, the liaison needs to build 
a contact network. 


Communicate and coordinate with other IETF liaison managers where 
the activities of two or more liaised organizations overlap. 
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8. Assist with the preparation of IETF liaison statements based on 
IETF consensus. 


9. From time to time, liaison managers and liaison representatives 
will have to report to the IETF on the status of the liaison 
relationship. For this purpose, they will need to keep track of 
outstanding issues on behalf of the IETF. The frequency of the 
reports and the recipients of the reports within the IETF will be 
decided when the liaison relationship is set up and may be 
changed at any time by an IAB decision. IAB or other parties 
within the IETF may probe for liaison reports as needed or at 
regular intervals. 


3.5. Relationship Management 


Liaison managers will be involved in activities for which they are 
not directly responsible, but that might greatly benefit from their 
expertise. Some of these activities are outlined below. 


3.5.1. IETF Consensus Process on Liaison Statements 


Liaison statements and other messages sent to a liaised organization 
should be based on rough consensus within the IETF or one of its 
working groups or areas. Though the liaison manager is not 
responsible for determining consensus, it is important that the 
liaison manager participate in the process and makes his or her 
expertise and knowledge available. 


How consensus is arrived at may vary according to the circumstances. 
Some issues are new, and in these cases an open discussion on a 
mailing list should be undertaken. For some issues, consensus has 
already been arrived at or the liaison statement is a mere statement 
of facts (e.g., to inform the liaised organization that an IETF Last 
Call had started on a document it had previously expressed interest 
in) and in these cases the liaison statement can be written and sent 
(such as by a working group chair), possibly involving the liaison 
manager. 


3.5.2. Incoming Liaison Statements 


When the IETF receives a liaison statement or other communication 
from an organization with which it has a liaison relationship that 
includes a request for a response to the communication, the IETF is 
committed to providing a timely response. This means that the IETF 
will respond within the time requested and provide information as 
accurately as possible. This commitment has been one of the key 
discussion points in the past, such as within the (g)mpls change 
process [GMPLS]. 
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This commitment does not mean that the IETF will uncritically accept 
the content in the incoming liaison statement. To the extent that 
the liaison contains requirements on IETF technology or protocols, 
they will be taken into consideration based on their technical merit. 


3.5.3. Ambiguous Incoming Liaison Statements 


Sometimes the IETF, an IETF area, or an IETF working group receives 
liaison statements from a liaised organization that are sent to the 
wrong destination. At other times, the liaison statement is sent to 
working groups that are not chartered to do the work that the liaison 
statement addresses. In some cases, it might be the situation that 
no working group is chartered to do the work. 


In such cases, the liaison manager should assist in finding the 
appropriate recipient within the IETF that might respond to the 
incoming liaison statement. Sometimes this might require that the 
intended response is made available for review on one of the IETF 
mailing lists. 


3.5.4. Liaison Managers Representing Peer Organizations 


Liaised organizations may appoint a person to act as a liaison 
manager for "their side" of the relationship. This is the person 
that will speak authoritatively, within the IETF, on the activities 
performed by the other organization. The other organization needs to 
make this person known to the IETF. This person might request a slot 
on a working group agenda to discuss developments and plans of the 
liaised organization. 


Opinions expressed by a liaison mangers of other SDOs, other than 
reports on work within the liaised organization, are given equal 
weight with opinions expressed by other working group participants. 
RFC 3356 [RFC3356] describes this in the context of the relationship 
between the IETF and the ITU-T; however, the same model is applicable 
to all other organizations with which the IETF has a liaison 
relationship. 


The mandates of liaison managers from other organizations are 
recognized by the IETF to the extent needed to understand the 
information received from the liaison manager. In all other respects 
he or she participates in IETF activities under the same conditions 
and rules as any other IETF participant. It is important that the 
IETF liaison manager understands the extent to which the peer liaison 
manager is mandated or delegated to speak on behalf of the peer 
organization, and to inform the relevant part of the IETF if the peer 
liaison manager appears to be stepping outside the role or stance 
given to him or her by the peer organization. 
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IETF liaison managers should work to include the liaison manager from 
the liaised organization within their contact network, and to 
understand the positions being communicated by the peer liaison 
manager. 


4. Security Considerations 


This document does not specify any protocol or "bits on the wire". 
However, since interaction with other standards-making organizations 
often relates to security, the liaison manager can assist with 
security-related issues, resulting in improved security for Internet 
protocols. 


5. IANA Considerations 


There are no requests to the IANA herein. Note that the liaison 
manager very often has to understand and convey questions regarding 
IETF namespaces managed by IANA. 
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